The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Certain network service providers operate large, complex networks that comprise thousands of infrastructure devices such as routers and switches. An interdomain routing protocol such as Border Gateway Protocol (BGP) is often used to manage the storage and interchange of path or route information among the infrastructure devices. BGP and other routing protocols use local route databases to manage route information. Such service providers may offer virtual private network (VPN) services to customers and may use multiprotocol label switching (MPLS) to forward data on VPNs.
Such service providers need to monitor the route databases that are stored in the infrastructure devices. For example, service providers may need to monitor Layer 3 VPN routes to determine if key routes have been removed from a customer's VPN. However, conventional approaches to monitoring such routes are CPU-intensive and are not scalable for high volumes of data. Some service providers use SNMP or Telnet to connect to each managed router individually and to collect or “poll” for data such as topology information, routing table entries, and MPLS labels. An approach that relies on individual device polling is not workable in large networks. There may be hundreds or thousands of routes to monitor on just one provider edge router of an MPLS-based network. Thus, a particular router may receive too many SNMP requests and may be unable to respond to all of the requests while still having enough processing power to perform packet routing and forwarding.
Further, a typical polling approach involves using SNMP to poll a router for an entire routing table, for example, using an SNMP GET BULK operation, and the table is then compared to a locally stored copy of the table to determine if any routing table information changed. However, if a loss of connectivity in an access circuit occurs or another connection loss occurs in the customer's own network, part of the routing table may be lost. Therefore, another SNMP poll operation must be performed and the entire routing table must be transmitted again. This burdens the target router with too much management traffic. Moreover, the routing tables are encoded using SNMP object identifiers, and SNMP data transfers involve transferring extensive encoding or formatting information in addition to actual route data. Thus, SNMP poll approaches are inefficient.
When BGP is the routing protocol, a BGP route reflector node could be monitored, but this approach places an undesirable traffic load on the node, which is a key device in the service provider's network. Further, the network management station is typically several physical “hops” away from a particular router or switch of interest, and therefore the network management station cannot use routing protocol adjacencies to obtain information from the router or switch.